Resolution Categorization
Configure Application Administration Console -> Custom Configuration tab -> Foundation -> Products / Operational Catalogs -> Generic Catalog Structure Category Type = "Resolution Category" Resolution Categories may be limited to certain Incident Types. Out of the box, an incident type of "User Service Restoration" provides the Resolution Category 1 "Failure", while an incident type of "User Service Request" provides the Resolution Category 1 "Request". Metadata Storage Main definitions are stored in CFG:GenericProdServiceAssoc (Alias: Generic/Product/Operational Relationship Category) Also, there is an association record with some flags set in CFG:GenericCompanyModuleAssoc. This record points to the main record with the following criteria: $GenericProdServiceAssoc ID$ = ‘R-GenericProdServiceAssoc ID’ The form CFG:GenericCompanyModuleLookUp joins these two config forms together. *Menu: CFG:PRC:CategoryHPD-Res-T1-Q **Lookup Form: CFG:GenericCompanyModuleLookUp ('Category Type' = "Resolution Category") AND (('S1' = $1000000063$) OR ('S1' = $NULL$)) AND (('S2' = $1000000064$) OR ('S2' = $NULL$)) AND (('S3' = $1000000065$) OR ('S3' = $NULL$)) AND (('P1' = $1000003891$) OR ('P1' = $NULL$)) AND (('P2' = $1000003892$) OR ('P2' = $NULL$)) AND (('P3' = $1000003893$) OR ('P3' = $NULL$)) AND (('Manufacturer' = $1000003896$) OR ('Manufacturer' = $NULL$)) AND (('Product Name' = $1000003894$) OR ('Product Name' = $NULL$)) AND (((('Company' = $1000000001$) OR ('Company' = "- Global -")) AND ($1000000001$ != " ")) OR ($1000000001$ = " ")) AND ((($1000000099$ = 0) AND ('Service Restoration Selection' = "Yes")) OR (($1000000099$ = 1) AND ('Request Selection' = "Yes")) OR (($1000000099$ = 2) AND ('Infra Restoration Selection' = "Yes")) OR (($1000000099$ = 3) AND ('Infra Event Selection' = "Yes")) OR (($1000000099$ = $NULL$) AND ('Help Desk Selection' = "Yes"))) AND ('Status-CMA' = "Enabled") AND ('Status-GPS' = "Enabled") Best Practices (From the BMC Communities) Bjorn https://communities.bmc.com/communities/thread/30183 A good rule of thumb would be, for example, to have the same set of Operational Categorization tiers than for Resolution Categorization tiers: an Incident should have been created with a wrong operational categorization, or maybe, during the incident's lifecycle, someone decides to change this operational categorization or maybe, when resolving the incident, someone decides that the correct categorization is different from the original one. This Resolution Categorization tiers, in my opinion, should be the same than the ones defined for the Operational Categorization. But this will involve a lot of work to do: it's a n-to-n relationship... I mean, for each Operational Categorization entry triplet, youll have n possibilities as output. Maybe there's a better approach, limiting the possible Resolution Categorizations for each Operational Categorization entered. But you'll still have a lot orf work to do initially and later, mantaining all this info. Steve Wilson https://communities.bmc.com/communities/thread/30183 The operational categorization is used to describe what kind of Incident it is. Failure > Software > E-mail, etc. Think of the operational categorization as a way to break down the summary of the incident into three tiers for easier searching, reporting, etc. The Resolution Categorization is used to breakdown the content of the Resolution field; i.e., how the Incident was resolved, into three tiers...also for easier searching, reporting, etc. Examples: Reset > Password, Hardware > Switch > Reboot, etc. So I don't think it's logical to have the same data in the resolution categorization as the operational categorization. If the intent was to do so, then that data would have been stored in the same form. Category:ITSM Category:Incident Management